The present invention relates to business software solutions. More specifically, the present invention relates to integrating business software applications automatically by applying prescriptive taxonomies, data models and schemas.
Integrated business software solutions typically include multiple functional products that support business segments and interact with enterprise hub and spoke networks. Such products include software applications related to financial information, human resource management, customer relationship management, professional services automation, distribution, supply chain management, and more.
Individual business software solutions have typically been provided by software vendors that generally provide an application development environment to allow the software to be customized for individual business applications. Traditionally, these business software solutions were designed as relatively stand-alone offerings in that they were complete in their database, data model, automation interface, screen technology, screens, and customization tools. Thus, a user of such solutions would purchase a given solution from a vendor; customize the solution for the specific business requirement; and provide the customized solution to an end user. Examples of business solutions include software systems sold under the trade designations: Solomon, Axapta, and Navision all of which are available from Microsoft Corporation of Redmond, Wash.
As a given customer's needs change, the customer may wish to add additional functionality to their business solution. This was typically done by either buying a new business solution that was capable of providing such features, or buying an add-on business solution that could be configured to cooperate with the legacy business solution. Difficulties generally arise whenever two discrete software systems are used in conjunction with one another, which software systems had not been designed for interoperation together. This problem gave rise to an industry that could generate customized interface adapter software to allow one software system to communicate with another software system. Generally, such adapters are one example of software known as middleware. The necessity of middleware and the degree to which it is focused upon individual combinations of software systems and business environments generally caused a significant increase in the overall system implementation cost because relatively large amounts of highly skilled software development engineer time was required. The design and implementation of middleware can include any number of known methods and techniques for interacting with business software systems. These can include techniques as simple as keystroke injection, screen shot analysis, interaction with the individual databases of the software systems, modification of the source code of the various software systems, or simply the provision of an adapter application that receives an output from one application, transforms the output into suitable input for the second application and feeds the input to the second application.
Another way that businesses adapt their application to changing business needs involves making customizations to the applications they have. Customizations are often applied at the time a new application is sourced, whether as a new purchase or as an adjunct purchase to meet the need described above. The challenge that business software vendors face is supporting this end customer requirement for customizable applications. There are a number of different techniques which have been conventionally used in order to enable a given system to be customized. These include source code customization approaches as well as integrated tool based approaches that allow end customers to add fields to tables and forms themselves. Each of the techniques listed above generally increases overall system cost, either by increasing the cost of developing the application in the first place, or passing the customization development burden on to the end customer. One example, source code modification, entails providing customers with copies of the source code for the product. It thus allows a well-trained practitioner to change significant portions of an application. Those changes can be made to look as if they are part of the product because, in effect, they are part of the modified source code product.
However, source code modification carries with it significant drawbacks. For example, source code modification costs a significant amount of money prior to using the product, because the user or customer must often hire expensive consultants and developers who have been specifically trained in the nuances of how the product is built. The user must then endure the risk of estimating a problem, which is a very difficult and imprecise task. Even if these problems can be overcome and persevered, the result is modified source code. When the manufacturer of the original source code for the modified application ships additional software, such as bug fixes, updates, and new versions, the customer is either forced to again hire talented engineers or developers (and hopefully the same ones who made the original modifications), in order to merge those modifications into the new source code shipped by the manufacturer, and to resolve issues, one-by-one, as they arise in the newly modified source code. Alternatively, the user can simply go without the bug fixes and new features that may benefit the user's business.
All of the above problems set forth with respect to source code modification are equally present with respect to the creation of individual software adapters that act in conjunction with middleware to go between discrete business software solutions. An adapter is generally configured to transform the given output from a first software system, for example, a customer ID number to a usable input for a second system. For example, the customer ID field in one system may need to be changed from a character string to a long integer to import the data into a second system. A change to the first system as simple as padding the customer ID number string with a letter prefix can cause the application integration adapter to fail because the prefix cannot be converted.
Most forms of middleware and/or adapters that are based on data transformation result in a relatively brittle set of code and/or cooperative software components. The fragile nature of adapter based integration approaches complicates the decision to apply important software updates to any of the components of an integrated set of software. Integration strategies based on middleware and adapters break down due to inherent fragility as well as the expense of reintegrating the entire system whenever an update to any of the individual systems is performed.
A new system for automatically integrating discrete stand-alone business solutions in a manner that is extensible, stable, and automatic is needed. Such a system would allow competing (and cooperating) software vendors to design and provide components that could easily be integrated into a business solution with minimal customization cost while similarly not adversely affecting system stability. Finally, such a system would be easily amenable to patches and updates such that individual product improvements could be easily applied to address concerns, shortcomings, and/or vulnerabilities that may be discovered in the future.